Is it less error prone if we error when we encounter UDP ports? On the other hand how do we want to forward the TCP part of something that has TCP and UDP ports. Just thinking out loud, no need to change something here.

UDP port forwarding is a bit iffy, and supporting TCP is enough for our use case. However, the implementation as is is just wrong if there is a UDP port, which is why I'm introducing the check.

On the other hand how do we want to forward the TCP part of something that has TCP and UDP ports.

You mean situations where both UDP and TCP need to be reachable for full functionality (like, a DNS server)? Fortunately, we don't need that.

I thought about that when using the function one might not read the documentation or just doesn't know if the port of a service is UDP or TCP and expecting a port forwarder. to put it another way: I thought about enforcing the comment in code by returning an error when we encounter non-TCP ports.

You mean situations where both UDP and TCP need to be reachable for full functionality (like, a DNS server)? Fortunately, we don't need that.

This was thinking about the consequences of return an error when we encounter non TCP ports. Then one would need to split every service that both has UDP and TCP ports into two in order to export the TCP ports.

I mean, it's not like you can kubectl port-forward UDP, and that is the only reason we have this pod. If this were a public library function I'd tend to agree, but I don't think we need to be this careful for an e2e test utility.

That being said, there's a bug in the current implementation which I only discovered because of this thread: if there are only non-TCP ports, the list is empty and the port-forwarder likely crashloop. In that case, returning an error is probably justified.